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MEMORANDUM TO: See attached distribution list 

FROM : Chairman, Apollo Software Configuration Control Board 

SUBJECT : Latest in Luminary for Apollo 14 

On July 22 we had an ersatz Software Control Board Meeting to go over 
what should be done with Luminary for Apollo 14. The problem that 
forced us to reopen this program is the error in forward and lateral 
velocity as displayed on crosspointers during terminal descent. Russ 
Larson and Don Eyles came down from MIT to explain to us just how this 
could be fixed in time for a mid-September program release. They also 
brought a shopping list of other possible changes we could make since 
we are already breaking open the program. Of these dozen or so possi¬ 
bilities, most of which were minor anomalies with remote chance of 
occurrence inflight, only two others are to be made. The purpose of 
this memorandum is to briefly describe the three changes we have agreed 
to. From this, it should be clear that the basic policy we are attempt¬ 
ing to follow is to minimize the number of changes even though MIT was 
confident they could include them all. In fact, they were anxious to 
do so for reasons of professional pride and satisfaction. 

As noted in a previous memo, the approach MIT prefers for fixing the 
crosspointer problem is essentially to relocate the Landing Analog 
Display Routine (R 10) from Don Eyles variable servicer offline assembly 
into the previously released Luminary assembly which has been through 
Level 5 testing. This new formulation of R 10 is preferred since it has 
been running and tested. Furthermore, it streamlines the coding such that 
it tends to minimize the increase in computer cycle time brought about by 
the more precise computations needed to eliminate the error. In the pack¬ 
age, whether we like it or not, a number of other improvements are accrued. 
They are: 

a. Eliminate the periodic '’lurch’' in the altitude-rate displayed on 
the tape meter. 

b. Correct the error and excessive granularity of the forward veloc¬ 
ity displayed in R1 of noun 60(during P66). 

c. Update display of altitude and altitude-rate each l/4 second 
instead of every l/2 second as at present. 

d. Begin displaying analog data at TIG - 30 seconds when average-G 
is turned on instead of waiting for ignition. 
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e. Eliminate the R10FLAG so that crosspointer displays be available 
during ascent and aborts as well as descent. 

Generally speaking, all of these things can be considered good with the 
possible exception of the last. The elimination of the R10FLAG makes 
the crosspointers active during ascent which has been informally requested 
by some of the crews to assist in monitoring out-of-plane velocity during 
that critical mission phase. The problem is, though, that during ascent 
the out-of-p±ane velocity of interest is inertially oriented whereas dur¬ 
ing descent it is with respect to the spacecraft. Thus, we are forced 
to do one of two things to Eyles* RIO - either suppress the display or 
provide the equations to make them right. In either case, the R10FLAG 
must be restored. We have left the decision to MIT to be based on which¬ 
ever is easier. 

With respect to cycle time, it is MIT’s estimate that the new RIO will 
decrease our margin by 0 . 85 % out of the total margin of 12$. This does 
not worry us particularly. 

One important item we assigned to Clarke Hackler (GCD) and Clint Tillman 
(GAEC), was to make sure that the Grumman hybrid facility (FMES) will be 
available for thoroughly checking this new program. This is absolutely 
essential since the problem most likely to be encountered will be software/ 
hardware compatibility and that is the only facility the verification can 
be done with real flight hardware. Initial testing can be done now with 
Don Eyles offline assembly to verify the formulation. Later we will want 
to put the flight program through its paces. 

Now I would like to go on to the other two changes we approved. The first 
is to change three fixed memory constants in the ascent propulsion system 
thrust program (p 42) in order to eliminate the 6 fps overburn we would 
nominally encounter at TPI. The rationale for this change is that it 
should be very straight forward and it fixes a deficiency we are certain 
to encounter if the mission goes as planned. The final correction to the 
program deals with the throttle instability during descent you’ve heard 
so much about. We are all convinced the changes made previously, i.e., 

IMU offset c. g. compensation and erasible memory control system gain 
changes, are more than adequate. On the other hand, it is recognized that 
a fixed constant describing the throttle hardware lags is clearly wrong. 

All of the control systems experts insist that there is no danger but 
only good things and joy if we change this constant, so it was approved 
pending a check into possible problems it might create in the initial 
throttle-down sequence in P 63 . If we do discover some such problem within 
the next several weeks we will revert to the old so-called wrong value. 

Just one word about the rest of the recognized anomalies we chose not to 
fix. As noted previously, none is likely to occur. That is, they are 
all involved in improper crew procedures or re-starts occurring during 
tiny windows affecting noncritical displays — things like that. Further¬ 
more, this occurrence is not particularly serious. 
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Russ Larson presented the following schedule which seemed quite satis¬ 
factory to our funny little hoard: 

a. July 31 - all coding complete. At this time an untested program 
is available for crew evaluation and testing external to MIT, 


b. August 17 - Level 3 testing complete, i.e., theoretically the 
program is ready. 

c. September 19 - release for rope manufacture. 
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